Peters School of Business · Assiniboine College · NETW-0001
Operating Systems Fundamentals · 5 days · 2 hours/day + Friday mini-assessment
Accounts, groups, and the Linux security model
Students who know Windows NTFS permissions will find a familiar mental model here — read, write, execute mapped to owner, group, and others — but implemented very differently. By Friday every student has created multiple users, assigned group-based file access, and understands how octal notation translates to rwx. Special permissions (SUID, SGID, sticky bit) close the week with real-world context.
Week at a glance
useradd, passwd, su, sudo, /etc/passwd and /etc/shadow explained
chmod, octal notation, permission matrix lab — rwx vs. other
groupadd, chown, chgrp, umask, group-based file access
SUID, SGID, sticky bit — /tmp, passwd, shared directories
Written: permission theory, octal. Practical: multi-user access scenario.
Week 2 target: Levels 3–6
This week's Bandit levels are a perfect match for the lab content. Level 3 hides a password in a hidden file (ls -a). Level 4 requires finding the only human-readable file in a directory. Level 5 uses find with size and permission flags. Level 6 searches the whole system by owner and group — exactly what students practise in Lab 3 this week.
ssh bandit0@bandit.labs.overthewire.org -p 2220 — password: bandit0User accounts — useradd, passwd, su, sudo, and the shadow file
/etc/passwd structure: username, UID, GID, home, shell. /etc/shadow — why passwords are stored separately and hashed. Root (UID 0) — the superuser. su vs. sudo — switching identity vs. borrowing privilege. Why root login is disabled by default in Ubuntu. Bridge: Windows has Administrator, Linux has root — both are dangerous to use casually.su root (fails — no password set). Use sudo passwd root to enable, then test. Create four users: lannistert, starkr, snowj, drogok — all password Room225. Create /lab3/docs directory, create four files inside. Observe default ownership. Experiment with switching between users using su./etc/passwd entry for one of their new users and explain each field. Preview Tuesday: now that accounts exist, how do we control what those accounts can access?Permission bits — chmod, octal notation, and the permission matrix
chmod u+x, chmod o-r) vs. octal chmod (chmod 755). The ls -l output decoded field by field. Bridge: NTFS has Full Control, Modify, Read — Linux has a simpler but more composable model./lab3/docs to each combination (r--, -w-, --x, r-x, rw-, -wx, rwx) and test with snowj: can they list? touch a file? cd into the directory? Record results in the table. Observe the counterintuitive result: -w- alone lets you write to a file but not list what's there. Restore defaults when complete.Groups, chown, chgrp, and umask
groupadd, usermod -aG, id to verify. chown user:group file — change owner and group simultaneously. chgrp for group only. Strategy: set group ownership on shared files, assign users to that group, control access via group permissions rather than individual permission assignments. umask: default mask applied when files/directories are created — 022 gives 644 files, 755 directories. Where is it set? /etc/login.defs and shell profiles./lab3/docs so that: directory.listing gives Tyrion full rights, Jon and Rob read/write, others read-only; finance.info gives Khal read-only, Rob and Tyrion no rights, Jon read/write; sales.info gives all users read/write; marketing.lies gives Jon read/write, and Khal/Tyrion/Rob read and execute. Students design and create the required groups, then set ownership and permissions. Test each scenario by switching users.Special permissions — SUID, SGID, and the sticky bit
/usr/bin/passwd — a regular user needs to change their own password, but /etc/shadow is only writable by root. SUID on passwd lets it run as root temporarily. Shows as s in owner execute position. SGID (Set Group ID): on a file — runs as the file's group. On a directory — new files created inside inherit the directory's group rather than the creator's primary group. Useful for shared team directories. Sticky bit: on a directory — users can only delete files they own, even if they have write permission on the directory. The canonical example: /tmp is world-writable but sticky, so users can't delete each other's temp files. Octal: SUID=4000, SGID=2000, sticky=1000.find / -perm /4000 2>/dev/null. Examine ls -l /usr/bin/passwd — observe the s. Verify /tmp has sticky bit: ls -ld /tmp. Create a shared group directory with SGID set — create files as different users and observe group inheritance. Attempt to delete another user's file in a sticky directory — observe the permission denied. Set SUID on a custom script and observe behaviour change.lsattr and chattr — immutable files. Set a file immutable with chattr +i and try to delete it even as root. Discuss the security use case.Mini-Assessment 2 — Users & Permissions
-rwxr-x---, identify owner/group/other rights and file type. Convert between symbolic and octal notation. Explain what umask 022 produces. Define SUID, SGID, sticky bit and give one real example of each. Describe the difference between su and sudo.Mini-Assessment 2 — Topic Coverage
| Topic | Weight | Format |
|---|---|---|
| Permission string interpretation (symbolic) | 15% | Written |
| Octal conversion (both directions) | 15% | Written |
| SUID / SGID / sticky bit — definitions and examples | 15% | Written |
| su vs. sudo explanation | 5% | Written |
| Create users, groups, directory structure | 20% | Practical |
| Set correct permissions per specification | 20% | Practical |
| Verify access by testing as correct users | 10% | Practical |
What you need ready before Monday